home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part2 / 10155 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  9.1 KB
  1. Path: nntp.teleport.com!sschaem
  2. From: sschaem@teleport.com (Stephan Schaem)
  3. Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,comp.sys.amiga.misc
  4. Subject: Re: AB3D II beats Quake....
  5. Followup-To: comp.sys.amiga.programmer,comp.sys.amiga.games,alt.sys.amiga.demos,comp.sys.amiga.misc
  6. Date: 28 Mar 1996 02:08:34 GMT
  7. Organization: Teleport - Portland's Public Access (503) 220-1016
  8. Message-ID: <4jcsb2$8te@nadine.teleport.com>
  9. References: <74000105753944194756@BIRDLAND> <10017.6659T1424T209@mbox.vol.it> <4jbcno$7m9@soleil.uvsq.fr>
  10. NNTP-Posting-Host: kelly.teleport.com
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. Nicolas Pomarede (pomarede@isty-info.uvsq.fr) wrote:
  14. : >I see again a future for CISC: as the most expert of you know, the RISC haven't
  15. : >been invented yesterday, they are old as me. The RISC vs CISC "war" has always
  16. : >been combacted with RAM speed as main arm: when the RAM were relatively slow,
  17. : >the CISC was faster than RISC; when the RAM technology was faster than CPU's
  18. : >one, the RISC's were faster than CISC's. CPU technology has grown up a lot
  19.  
  20. : I don't really agree with this one. Everything depends on the build-in cache
  21. : and the memory it uses. RISC has been designed to provide a more simplified
  22. : intruction set that should be easier and faster to decode.
  23. : Anyway, there's actually no RAM that can cope today with a 68 Mhz CPU
  24. : (at least not on a personnal computer). 68 Mhz means 14.7 ns RAM ; I don't
  25. : think you can have many megs of this kind of RAM. This kind of RAM is only
  26. : used in 8/32 K cache (or in VRAM), but in that case, both RISC and CISC
  27. : can use this RAM (SRAM), so the RAM don't make a big difference IMO.
  28.  
  29.  I think L1 cache even at 200mhz offer 0 waitsate... and I also recall
  30.  PC having 512k of 8ns L2 cache, for 99$.
  31.  larger system like servers can sport 4meg of cache.
  32.  
  33. : >Advantages? 80x86 can contain upto 4 instruction codes into 32bit, while the
  34. : >PowerPC can contain only 1. This means that parallelization will allow 80x86
  35. : >to run 4 times faster than the fastest of PPC.
  36.  
  37. : The problem is not the size of the opcode, it's the time needed to read it.
  38. : All modern CPU read opcode in one cycle, and since buses are 32 or 64 bits,
  39. : reading 8 bit is usually a waste of power.
  40.  
  41.  
  42.  He was talking about cache fill. usually 16bytes are read at a time.
  43.  For a cisc like the x86 this can be equal to 16 instruction, on a risc
  44.  4... This would really mater if the CPU had no L1 or L2 cache.
  45.  
  46. : One of the big problem of the Pentium and 680x0 is that the opcode are not
  47. : of the same size. 680x0 can have opcode of 2,4,8,10 bytes and x86 can even
  48. : have opcode of one byte (those compatible with 286).
  49.  
  50.  Yes, and it a 'problem' that intel with work took to their advantage.
  51.  The 680x0 for example could have a risc core that only implement 16bit
  52.  instruction, the other would use interpreted code. You have to make
  53.  the compiler aware of this so it optimize your code using the best
  54.  instructions... I think this is what happen with 16bit code on P6.
  55.  
  56. : On the other hand, RISC CPU have all their opcode with the same length
  57. : (usually 32 bits) ; in fact, while RISC was meant to have a Reduce Instruction
  58. : Set, this is today not that true. RISC is now mostly caracterized by the fact
  59. : that opcode all have the same size, which allow massive predecoding of the
  60. : instruction flow. RISC CPU can predecode up to 8 instructions in parallel,
  61. : because they know that every 32 bits there's a new intruction.
  62.  
  63.  Actually the P6 can issue 3 instruction per cycle... its a very good
  64.  performer in the integer area. Something that chip like the R5000
  65.  do is mul+add in 1 insruction, more common to risc is move+logical operation
  66.  in 1 instruction.
  67.  
  68.  move.l    d0,d1
  69.  add.l    d2,d1
  70.  
  71.  take 32bit, on a risc can look like
  72.  
  73.  add    d1,d0,d2
  74.  
  75.  Also 32bit
  76.  
  77. : On CISC, it's  not possible, because opcode are not 32 bit aligned. This means
  78. : that before decoding intstruction i, you must decode instructions 0 to i-1.
  79.  
  80.  Thats not a problem really... x86 nowdays have a risc core and decode the
  81.  x86 'language'. I heard that maybe 18% of the P6 is actually x86 related
  82.  the rest is just risc design.
  83.  
  84. : This way RISC can also implement powerful branch prediction, which tend to
  85. : add no overhead whether the branch is taken or not.
  86. : Such prediction technology are not usable in CISC ; using them would mean
  87. : adding thousand of transistors that could be used to speed up other
  88. : instructions.
  89.  
  90.  The P6 seem to show that cisc with alot of effort can perform pretty well.
  91.  
  92.  
  93. : >
  94. : >We'll get soon BiCMOS technology for CPU's: 700Mhz, while the RAM will run at
  95. : >a speed hugely inferior. That day (in 1-2 years) having more concentrate
  96. : >programs (80x86 = upto 8 instructions every 64bit / PowerPC = upto 2) and
  97. : >being able to perform more things with each instruction ( = CISC philosophy)
  98. : >will outperform RISC's of lotsa times.
  99.  
  100. : Again, I don't agree. The problem is not the size of the opcode, but the time
  101. : needed to execute it. Allowing 1 byte opcode means you won't be able
  102. : to do pipelining and predecoding of the instructions flow.
  103. : I don't think any chip firm today would go that way, ie using 1 byte
  104. : opcode.
  105.  
  106.  Its hard to say what would be the best instruction size/format...
  107.  
  108. : For the 700 Mhz, I don't know if this will be reached in standard computer.
  109. : 300/400 Mhz will certainly, but IMO, the next step in speeding up will be
  110. : having more than 1 CPU in parallel. From this point of view, I think the
  111. : BeBox is a good first attempt in this direction.
  112.  
  113.  Risc/cisc are going that way yes... Personaly I see the future in multiple
  114.  core CPU and new programing language (getting away from the linear 
  115.  flow design)
  116.  
  117. : >Intel is not dumb, they said 3 years ago what I understood nowadays.
  118. : >Time for other people to understand it as well.
  119. : >
  120. : Intel is producing mass CPU, not clever CPU. I'm much more interested in
  121. : work and advices from HP, MIPS, ...
  122.  
  123.  
  124.  Intel also design advance risc that even SGI used for high end geometry
  125.  engine. HP also use intel risc in mass quatity. Intel is not stupid and
  126.  has ALOT of resource to take crap design like the x86 and turn it around
  127.  to be a performer.
  128.  
  129. : >The only thing that can allow a future to RISC is ~5ns RAM, which is unlikely
  130. : >to happen, indeed.
  131. : >
  132. : >So, we are back again.
  133. : >The AmigaPPC604 (note: expensive high-end model) is not standard yet, while the
  134. : >200Mhz PentiumPro is already available and going to be surpassed soon by the
  135. : >new much faster 80686/80786 "lotsa-Pentiums-into-a-chip" processors.
  136. : >
  137.  
  138. : One of the big problem with the x86, is the poor number of register and the way
  139. : they have to be used. Really, having 32 or 64 regs (PPC) greatly helps
  140. : speeding up execution (as an  ASM supporter, I think you will agree on the
  141. : importance of the number of registers).
  142.  
  143.  I think the x86 use 'stack' register... I dont think the MIPS cPU support
  144.  indexed store, but a X86 can use this VS register
  145.  
  146.  add    virtual_register1,register1
  147.  
  148.  On the 040 this 
  149.  
  150.  add.l    (virtual_register1,a7),d0
  151.  
  152.  is not slower then
  153.  
  154.  add.l    d1,d0
  155.  
  156.  
  157. : One of the proof to this is that a 68060/66 runs at the same speed as a P133
  158. : (this has been shown with some lightwave rendering, taking approx 12-13 min
  159. : on both machines).
  160.  
  161.  I think this also show that the 680x0 as been optimized over a few years.
  162.  Also the x86 is not knowed for its floating point performance.
  163.  
  164. : For me, future will be be having many RISC CPU in parallel. This is already
  165. : done in SGI renderer, and I doubt they would do it if it wasn't worth.
  166.  
  167.  You can go to www.mips.com (MIPS is owned by SGI, like cray) and check
  168.  out their R5000 (would be nice for a high end amiga, the low end could
  169.  use R4600). 
  170.  
  171.  
  172. : From what I read in your previous post, you seem to be asm addicted and not
  173. : really pro-C. In fact, I was like you a few years ago ; I only swear by ASM;
  174. : I wanted to rewrite everything in asm, patch slow functions in the OS, etc...
  175. : But I changed my mind, I'm now also working on HPUX server, that run C code
  176. : quite fast. A general rule in computing says that 90% of the CPU power is spent
  177. : in only 10% of the whole code of a program. In that case, writting a portable
  178. : OS is possible (you could then make specific asm speed up on some platform).
  179.  
  180.  100% asm is silly in 99% of design (I love estimation:), but in rare case
  181.  like doing a rendering engine you might want to stay 100% asm, just so you
  182.  dont have to handle a few scatered C file and a C compiler /interfacing :)
  183.  
  184.  So far asm as been simple, but CPU get more complex now and compiler
  185.  are bound to do better jobs overall. only a few expert will be left 
  186.  optimizing really time critical tight loops :)
  187.  
  188. : I still enjoy coding in asm, but I'm also open to other language.
  189. : I agree with you on the point that next Amiga shouldn't only have some kind
  190. : of SVGA cards. For me, a dream machine would be a mixing of a fast PPC604
  191. : and sthg like the PSX or Saturn video hardware.
  192.  
  193.  I consider 680x0 a fun easy language :) x86 a pain in the brain... 
  194.  PSX/saturn 3d is pale comapre to the U64. The PSX use a 33mhz R3000,
  195.  the U64 a 100mhz R4000... The U64 video HW with a 1280x1024 res would
  196.  be very nice, specially because it would come from a mass produced 
  197.  chipset , so cheap. The U64 R4000 100mhz could be the geometry
  198.  engine sitting next to the R5000 (400mflop for <300$) main cpu.
  199.  
  200.  Stephan
  201.  
  202.